勉強中

工事中
4. SOTIF活動の外観と組織,,,,,,
,4.1 概要,,,,,
,Clause4は以下を提供する,,,,,
,a),SOTIF原則の外観,,,,
,b),SOTIF活動のワークフローとこの文書の使用のガイダンス,,,,
,c),SOTIF活動の管理とプロセスの支援のガイダンス,,,,
,この文書で記述されている活動は車両、システムおよびコンポーネントレベルに適用できる,,,,,
,4.2,SOTIF原則,,,,
,,4.2.1,SOTIF関連有害事象モデル,,,
,,,この文書の主要目的は、SOTIF関連有害事象に関するリスクレベルが十分に低いことを確実にするために使用される活動と論理的根拠を記述することである,,,
,,,機能、関連するユースケースを含むシステム仕様と設計、はいくつかのシナリオを包含する。これらのシナリオは、危害に至るトリガー条件を含むことがある(単純なバージョンは図4を、より詳細なバージョンは図1～3を参照)。危害を避けるために、適切な状況認知が必要である,,,
,キー,,,,,
,a,トリガー条件は合理的に予見可能な直接的な誤使用を含む,,,,
,b,有害事象の制御が出来ないとは、合理的に予見可能な間接的な誤使用の結果であり得る、例えばドライバーが行うと想定されている管理を行わない,,,,
,図4,SOTIF関連有害事象モデルの妥当性確認,,,,
,,,,,,
,,,例1,郊外での設定が有効にされたとき、高速道路のみでの使用が意図された機能が、交通弱者の動きの認識と解釈が困難である,,
,,,例2,、たとえシステムが無効でも、有効であると推測しているドライバーといったシステムの運用モードの正しくない理解。そのような状況では、この鳥違いを防止するための可能性あるシステムHMIの不足、あるいは適切なシステムの応答がないこと(ドライバーの振る舞いは監視されている場合)もシステムの有害な振る舞いと考えられうる,,
,,,注記1,適切な状況認知は以下を信頼する,,
,,,,・関連環境条件が十分に理解できて正確に認知される(例えば、関連する停止標識の検出)と、各道路利用者の予測モデル(例えば、進行方向、速度)。状況認知は、更に現地化、自車動作、あるいは他の車両との通信あるは環境といった情報で更に支援されうる,,
,,,,・運転中の適切な行動あるいは応答(例えば、停止標識に関するルールに従う),,
,,,,車両運用ライフサイクルを通じて、以下は多種である,,
,,,,・環境(例えば、新しい種類の交通標識、路面表示、車両),,
,,,,・適切な応答(例えば、新しい交通標識、運用シナリオの変更、運行法規の変更、に対必要な新しい運転行動),,
,,,注記2,このような変更の監視は、この文書のClause13で扱われる,,
,,,注記3,運転ポリシーのために導出された要求によって、このような考慮がカバーされるかもしれない,,
,,,このような考慮は、,,,
,これらは、運行中にSOTIFを確実にするために、運行設計領域(ODD)の仕様化とシステム開発中(リスク識別、適切な対処の定義)の際に考慮される,,,,,
,,,,,,
,,4.2.2 4つのシナリオエリア,,,,
,,,この文書内で、有害なシナリオとは有害なふるまいの原因となるシナリオである。関連するユースケースの一部であるシナリオは4つのエリアに分類される(図5と6を参照),,,
,,,,,,
,,,"エリア1,2,3,4はこの文書を理解するために、以下のように構造化してガイドするよう定義されている",,,
,,,・既知で無害のシナリオ(エリア1),,,
,,,・既知で有害なシナリオ(エリア2),,,
,,,・未知で有害なシナリオ(エリア3),,,
,,,・未知で有害なシナリオ(エリア4),,,
,,,例　未知のエリアは以下のようなとkにシナリオにかかわる,,,
,,,,・可能性のあるトリガー条件が定義される(例えば、極端に低い温度、特殊な運転シナリオの組み合わせ)が、システムの振る舞いは未知である,,
,,,,・未知のトリガー条件が存在する(例えば、極めてまれな事象),,
,,,,・シナリオの既知のパラメーターは、未知の可能性あるトリガー条件と組み合わされる(例えば、天候と交通条件),,
,,,注記1,未知だが無害なエリア4のシナリオは危害のリスクを負わせない。エリア4のシナリオがひとたび発見されたら(言い換えると、既知になると)、エリア1に移行する,,
,,,このモデルは、以下のために、SOTIF活動のゴールに対応する概念的抽象化に対応する,,,
,,,,・意図機能の解析に基づく、エリア2のリスク可能性評価の実施する,,
,,,,・エリア2で、有害な振る舞いを引き起こす既知の有害なシナリオの可能性を、機能変更を通じて受容可能基準まで低減する,,
,,,,・エリア3で、可能性のある有害な振る舞いを引き起こす、未知のシナリオの可能性を、適切な検証と妥当性確認戦略を通して受容可能基準まで低減する,,
,,,注記2,これは、エリアの大きさが計測できないことによるタスクの一つの側面の単なる概念的なアプローチである,,
,,,注記3,エリアの大きさは、シナリオによるリスクではなく、シナリオの数に対応する。しかしながら、これは、エリアの大きさが実際には計測できないことによるタスクの一つの側面の単なる概念的なアプローチである。SOTIFタスクは、意図機能のリスクが十分に低いことの論拠を提供することであり、シナリオの数は一つであるが、ただ一つではない。結果として起きる危害の深刻度や有害なシナリオの発生の発生確率は意図機能のリスクの一員となるが、このエリアには対応しない。,,
,,,注記4,エリアの大きさは、シナリオの数を表現するが、シナリオによるリスクではない。SOTIF活動のゴールは、意図機能のリスクが十分に低いことの論拠を提供することであり、シナリオの数はいくつかある側面の一つである。結果として起きる危害の深刻度や有害なシナリオの発生の発生確率は意図機能のリスクの一員となるが、このエリアには対応しない,,
,,,,訳注：注記3と4の記述はほぼ同じであるが、翻訳時の誤記ではない。原文自体がほぼ同じである。同じ内容を続けて書いている意図は不明である。,,
,,,注記5,確実にSOTIFに関連する活動のシナリオの利用が、適用されたシステム開発アプローチで計画されない場合、不合理なリスクを避けるというSOTIFのゴールを変えない,,
,,所定のユースケースは、既知と未知のシナリオを含みうる。それぞれのユースケースのシナリオ探索は、従来知られていなかったシナリオの識別に繋がる可能性がある。,,,,
,,SOTIF活動の最終ゴールは、それらのシナリオで起きる残存リスクが十分に低い、言い換えると受け入れ可能基準以下である、という論拠を提要するために、エリア2と3で示される可能性ある有害な振る舞いを評価することである。エリア2の既知のシナリオに起因するリスクが明確に評価されていても、エリア3の未知のシナリオに起因するリスクが十分に低いと、静的テストによって論証される。,,,,
,,エリア2と3による残存リスクは低減されることが期待される。SOTIFの達成への信頼はエリア1のシナリオセットの拡大荷によって増加する(図7と8参照),,,,
,,4.2.3　sense-plan-actモデル　(訳注：あえて、日本語を当てていない。以後、センス・プラン・アクトモデルとカタカナ表記する。日本語にするとすれば、「認知・計画・行動」モデルか？だが、意味的に「計画」はあまり適切でない気がする),,,,
,,,この文書で考慮される、有害な振る舞いの可能性のある原因は、システムが十分に正確な環境モデルを作成し、正しい判断を行い、正確な環境モデルに基づいた正しい制御行動を起こし、制御行動を実行する能力に強く関係する,,,
,,,キーとなるシステムエレメントとその相互作用は、「センス・プラン・アクト」モデル(図9参照)に代表される。「センス」エレメントは、認知(ローカリゼーションを含む)の部分を実行する、言い換えると車両とシステム状態と同様に車両内外の環境のセンシングから得られた情報に基づく環境モデルの作成である。「プラン」エレメントはゴールとポリシーを「センス」エレメントから提供された環境モデルに当てはめて、制御行動委を起こす。最後に、「アクト」エレメントは制御行動を実行する。,,,
,,,,注記,決定アルゴリズムは「センス・プラン・アクト」モデルのすべてのエレメントに含まれる(例えば、分類、センサーデータ、状況分析、行動決定),
,,,センス・プラン・アクトモデルに基づいて、システム全体のアーキテクチャは効率的なSOTIFプロセスの達成のために重要な考慮事項となり、すべての能力と対応する活動は機能開発ライフサイクルの初期ステージと全体にわたって起きる。利用可能なシステムアーキテクチャの選択は、SOTIFを確実にするために重要である。それゆえ、システムアーキテクチャの定義に相当する活動は、システム開発の初期ステージに行うことが出来る。更に、システムアーキテクチャはシステムライフサイクル中に定常的にレビューされ、必要に応じてこうしんされる。,,,
,4.3　この文書の利用,,,,,
,,4.3.1　フローチャートとこの文書の構造,,,,
,,,SOTIF活動(図10参照)は、仕様と設計(Clause5参照)から始まる。仕様と設計は、下流のSOTIF活動とサイクルの前にすでに知られている、性能制約と機能不足をすでに含んでいる。SOTIF活動のイテレーションは、仕様と設計を更新すること、以前には発見されていなかった性能制約と機能不足(の発見)に繋がり得る。仕様と設計から始まる各イテレーションは、どんどん更新される仕様と設計に寄って立つ,,,
,,,機能不足の可能性ある有害な振る舞いは、ハザード識別とリスク評価(Clause6参照)の対象となる。識別された有害な事象は適切に定義されたリスクとリスク受容基準に関連して評価される。有害な事象が不合理なリスクに繋がらない事が示されるなら、追加方策は適用されない。Clause6は意図機能の有害な振る舞いの原因を考慮しないが、ただ安全の根拠のみを考慮する。それ故、有害な振る舞いに起因するかもしれない有害事象の評価、および適合することが求められる受け入れ可能基準を定義することが焦点である。,,,
,,,Clause7は意図機能の有害なふるまいのありうる真因を識別し、識別した可能性ある機能不足に起因するリスクとトリガー条件が合理的であるかを評価する。,,,
,,,"機能は、Clause6,7,9,10,11,12および13の活動の結果として必要と考えられるならば、SOTIFを改善するために変更(例えば、センサー能力の向上、ODDのさらなる制限)される(Clause8参照)",,,
,,,検証と妥当性確認戦略は、SOTIFに関連する車両レベルの残存リスクは受容可能レベルを下回る、及びエレメントが機能要求(Clause9参照)に適合していてODDを通したカバレッジが十分である、という証拠を提供するために、開発される。必要な証拠の収集を有効にするために、対応する検証テストケースはこの戦略から導出され得て、ODDを通したテストケースカバレッジは十分高い。,,,
,,,SOTIF活動の結果がSOTifを達成しているという論証に十分であるかどうかを評価する。,,,
,,,市場で発生する可能性ある運用上のSOTIF課題の評価と解決のプロセスは、運用フェーズで定義される(Clause13),,,
,,,図10は意図機能の安全を確実にするためにこの文書で要求される活動の流れを記述する。丸数字は対応するこの文書のClause番号を示す。,,,
,,4.3.2　基準となる章,,,,
,,,この文書への準拠は、章の最初にリストされた目標の一覧化すること、目標が達成された対応する作業成果物に文書化されていることの論拠を提供することによって主張される。この目標の基準特性は要求事項であることを示す「Shall」というキーワードで表現される。,,,
,,4.3.3　表の解釈,,,,
,,,この文書のいくつかの表は、確かな開発目標を達成するための手法や方策の集まりを列挙する。その要素は可能性ある手法や方策を説明するという重要性を持ち、表全体は網羅的ではない。他の同等の手法や方策は適用できる。表の意図は開発チームが適切な手法や方策を選択することを支援することである,,,
,,,注記,適切な手法のセットの選択は、有害事象の複雑性や暴露性と言った、いろいろな要因に依存しうる,,
,4.4 SOTIF活動の活動と支援プロセス,,,,,
,,4.4.1 品質管理、システムエンジニアリングと機能安全,,,,
,,,安全な製品を開発するために、厳密なエンジニアリングと品質管理プロセスが基本となる。それらはすでにIATF16949，ISO26262シリーズおよびISO/IEC/IEEE15288といった、他の規格で取り扱われている。この文書はそれらのプロセスのSOTIF特有の側面にのみ焦点を当てる。,,,
,,,注記1,製品開発の間、この文書で述べられている活動とISO26262:2018シリーズは平行して実施できる。一般的に実施される方策は機能安全と対してと同様にSOTIFに影響を与え得て、両方の原則によって評価される。6.1はISO26262-2018とSOTIFを平行して実施する実践的なガイダンスを提供する。,,
,,,"管理的活動と支援プロセスISO26262-2,ISO26262-7およびISO26262-8はSOTIF活動にも拡張できる。連なる要求とトレーサビリティへの特別な注意が5.3および10.2で述べられる。",,,
,,,SOTIF関連活動のために、手法と方策のセットが以下のように選択される,,,
,,,・SOTIFプロセス(図10参照)はシステムの仕様と設計およびそのアーキテクチャから始まる(Clause5参照),,,
,,,・意図機能の有害な可能性のある振る舞いは、ハザードとその対応する有害事象を識別する、ハザード識別とリスク評価(Clause6参照)の対象である。それらの有害事象が危害の不合理なリスクに繋がらないと示されたなら、追加の設計方策は適用されない。,,,
,,,注記1,Clause6は意図機能の有害な振る舞いの原因ではなく、その安全への結果のみを考慮する。それゆえに、有害な振る舞いに繋がり得る有害事象の評価と、適合すべき受け入れ基準の定義に焦点を当てる。(訳注：注記番号が重複しているように見えるが誤訳ではなく原文通りである。これは、上記の「意図機能の有害な～」の注記と解釈される。インデントされていないため、不明確である),,
,,,・Clause7は意図機能の有害な振る舞いの可能性のある真因を識別し、識別された可能性ある機能不足によるリスクとトリガー条件が合理的であるかを評価する,,,
,,,"・機能は、Clause6,7,10,11,12及び13の活動の結果として必要と見なされるなら、SOTIFの改善のために変更される(例えば、センサー能力の改善、ODDのさらなる制限)(Clause8参照)",,,
,,,・検証と妥当性確認戦略は、SOTIFに関連する車両レベルの残存リスクは受容可能レベルを下回る、及びコンポーネントが機能要求(Clause9参照)に適合している、という証拠を提供するために、開発される。対応する検証と妥当性確認のテストケースは結果としてのリスクが十分小さいことを評価するためにこの戦略から導出される。,,,
,,,・残存リスクは、それまでの活動の結果を考慮して、評価される(Clause12参照),,,
,,,・市場で発生する可能性ある運用上のSOTIF課題の識別と解決のプロセスは、開発フェーズで定義され、運用フェーズで実行される(Clause13),,,
,,,注記2,ISO26262:2018に準拠した機能安全とこの文書の間の相互作用に関するさらなる説明はA.2にある,,
,,4.4.2　分散SOTIF開発活動,,,,
,,,分散製品開発の場合、開発合意協定(DIA)が関係組織間で定義される。DIAのゴールは、プロジェクトの初期ステージですべてのSOTIF活動の責務と、適切な技術情報が開発関係組織間で交換されることを、確認することである。,,,
,,,"IATF16949は、このコンテキスト内で考慮されうる、基礎的なプロセスフレームワークを提供する。この副章はどのようにDIAをSOTIF分散開発と分散運用に拡張するかに焦点を当てる。ISO26262:2018シリーズはDIAと機能安全の側面の供給合意のフレームワークを提供する。このフレームワークをSOTIFに適用するために、SOTIF開発と運用に関連する各組織の責務を追加することで、テーラリングが適用できる。各組織の責務は計画で考慮されて合意され、Clause5から13のすべてのSOTIF関連活動を実行する。共有される情報と作業成果物は公的に記述される。これらの活動は、ISO26262-8:2018,5.4.1,5.4.2,5.4.3,5.4.4及び5.4.6で記述された、そしてSOTIF活動のためにテーラリングされるプロセスを使って実施できる。文書化フォーマットは開発プロジェクトの開始時点で合意される。",,,
,,4.4.3　SOTIF関連のコンテキスト外エレメント,,,,
,,,SOTIFを達成するために、異なるシステム(HWおよびSW)の間のインターフェースは記述されることが基本である。統合されたシステムが特定のODDないで安全であることを確実にするために、各システム(例えば、スタンドアローンのセンシングシステム)の境界は注意深く評価される。環境要因(例えばODD)がSOTIF開発の根本課題であるために、システムとそのエレメントには各改装に依存する異なる関心事項がある。そのようなシステムとエレメントの開発に関する限り、それらは以下の3種類に分類されうる。,,,
,,,a),"コンテキスト内開発：システムはV字モデルに従うSOTIFのすべての活動を用いて開発される。システムとそのエレメントを開発する分散された組織のためには、要求事項が仕様とデザイン(Clause5参照)および他の活動(Clause6,7,8,8,9,10,11,12及び13参照)を含んで、役割割り当てに従って決定される。ISO26262の用語で、この開発は「コンテキスト内」開発と考えられる",,
,,,b),"コンテキスト外SOITF関連エレメント：これらのエレメントの仮定はそれらの全システム内での使用と意図機能への貢献に関連して作成される。そのようにSOTIF関連の出力不足とその許容される発生目標レートに関連する仮定を作成することが可能である。これらの仮定は後続のエレメント開発への入力として文書化され使用される。SOTIF活動は関連する対応する目標レートが適合するという証拠を提供する。SOTIF関連コンテキスト外エレメントのために、識別されたエレメントのトリガー条件と結果としての出力不足は使用の仮定にそって文書化される。SOTIF関連コンテキスト外エレメントを統合するとき、仮定の妥当性確認は、全車両レベルの機能のコンテキストでのSOTIF活動によって確立される(ISO26262-10:2018,Clause9SEooC参照)",,
,,,c),SOTIF関連開発指定なし：これらのエレメントの機能は意図機能に様々な方法で貢献しうる、そのため、エレメントが使用されるであろうコンテキストなしで、SOTIF関連要求は本来備わっていると推測することが現実的に可能ではない。,,
,,,,例,GPUに割り当てられた要求はシステムのコンテキストとGPU上で動作するSWに依存する,
,,,,,,
5,仕様と設計,,,,,
,5.1,目標,,,,
,この賞の目的は、以下の目標を達成することである,,,,,
,a),仕様と設計が、SOTIF関連活動を運営するのに十分な情報を含まなければならない,,,,
,b),仕様と設計が、SOTIF関連活動の各イテレーションの後で、要求に応じて更新されなければならない,,,,
,,,,,,
,5.2,設計のための機能の仕様と考慮,,,,
,仕様と設計は、章・節でリストされたような、いろいろな側面を含むことが出来る。いくつかの側面は、特定の自動運転レベルあるいは、特定の実装にのみ関連する。加えて、いくつかの側面は、車両レベルといくつかのエレメントレベルの機能の仕様に関連する。,,,,,
,考慮すべき側面は、以下を含むが、それに限られない,,,,,
,・意図機能の記述と、それを支援するサブシステムやコンポーネントの機能；以下を含む,,,,,
,,・ODD(運航設計領域),,,,
,,・車両の自動運転制御権限のレベルと詳細,,,,
,,・VLSS(車両レベルのSOTIF戦略),,,,
,,・機能が有効/無効である、および、有効/無効間の遷移が起きるユースケース,,,,
,,・意思決定ロジックの記述(例えば、経路計画、運転ポリシー　Annex D.1参照),,,,
,・関連システムの摂家音そのエレメントへの意図機能の実装,,,,,
,・導入されたセンサー／制御器／アクチュエータあるいは他の入力／および(例えば地図といった)意図機能を実行させるコンポーネントの性能目標,,,,,
,,注記1,自動運転システムの性能目標は、例えば、ODD内での危険な物体や事象(例えば、歩行者、車両、自転車、二輪車および交通標識)の検知と応答とである,,,
,・意図機能の、以下の事物への、依存性/相互作用あるいはインターフェース,,,,,
,,・ドライバー,,,,
,,・ドライバーインターフェース(たとえば、HMI)、および既知の合理的で予見可能な誤使用を緩和するために如何にインターフェースが使われるか,,,,
,,・リモートオフィスおよびバックオフィスの運用者,,,,
,,・乗員、歩行者、サイクリストおよび他の道路利用者,,,,
,,・関連する環境条件,,,,
,,・道路インフラおよび道路施設,,,,
,,・クラウド、車両間、あるは他の通信インフラ(例えば、V2X/X2V Annex D4参照)、および診断やパラメーター更新に関わるやテレマティックサービスとの間のデータ交換,,,,
,,・ソフトウェアアップデートのリモート送信,,,,
,,・意図機能と情報交換を含むインターフェースするかもしれない、車両の他の機能、と対応する用途の仮定,,,,
,・合理的に予見可能な誤使用(直接的および間接的),,,,,
,・可能性のある性能の限界、システムとエレメントの識別されたトリガー条件と対策,,,,,
,,注記2,SOTIF活動中に識別された可能性ある性能限界とリスクは、受け入れられ、「対策」がない可能性がある。そのような状況で、それらは仕様と設計の中に文書化されうる,,,
,・意図機能を実装するシステムと車両のアーキテクチャ,,,,,
,・警告と格下げのコンセプト,,,,,
,,・警告戦略,,,,
,,・DDTフォールバック：対応するユースケース内での、自動運転システムからドライバーあるいは他のシステムへの、バトンタッチと代行条件および遷移制御スキーム,,,,
,,・MRC(ミニマルリスクコンディション)スキーム(例えば、自立的に車線を離れて駐車、道路での停止、予備対応時利用者),,,,
,,・フォールバック戦略におけるドライバー監視システムとその運用効果,,,,
,・意図機能の開発中と開発後の、データ収集と監視を支援する手順,,,,,
,,・データ収集の目標と要求事項,,,,
,,・SOTIFリリース以前に要求されるデータ収集を支援するアーキテクチャ、実装およびメカニズム,,,,
,,・SOTIF分析(13.5参照)の運用フェーズの間のデータ収集を支援する、要求事項、設計及びメカニズム、クラウドベース、「OTA」あるいは無線通信技術などをを含むかもしれない,,,,
,・運用中のリスク緩和を支援するメカニズム、設計および要求事項,,,,,
,5.3 システム設計とアーキテクチャの考慮事項,,,,,
,仕様と設計は、システム／そのエレメント／その機能および性能目標の適切な理解を提供し、サブフェーズの活動が実行されうる。,,,,,
,これは、既知の機能不足の徹底的なリストを含み、それはトリガー条件や、適用可能なら対策に関連する。いくつかの可能性のある機能不足、トリガー条件、および対策はSOTIF関連プロセスの開始前に知られ文書化され、そのほかはSOTIF活動の結果として公開される。システムは、対策が既知の機能不足の影響を全システムで緩和するために実装されるように、設計される。,,,,,
,SOTIF関連活動の各イテレーション(図10参照)は、関連するレベルでの仕様と設計の更新に繋がり得るエンジニアリング活動に繋がりえる。各イテレーションは設計とは、関連するレベルで更新された仕様と設計に頼ることで、それは前のイテレーションで発見されたすべての情報を反映する。,,,,,
,"開発組織(OEM,Tier1,TierN)の中での共同作業が、統合されたシステム/コンポーネントあるいはエレメントの可能性ある機能不足の発見に、そしてシステム開発フェーズ中のそれらの影響への対策の開発に、必要である。設計と仕様の関連する部分は、下位レベルのシステムとコンポーネントの開発者に伝達さる。各開発サイクル/イテレーションの後で、使用の仮定、予見可能な誤使用、及び可能性ある性能限界は、あるTierから次の階層のレベルに伝達され、OEMを含む所まで伝わる。",,,,,
,SOTIF活動が新たな機能不足とトリガー条件を識別するように(Clause7参照)、そしてSOTIFを改善する施策が定義されるように(Clause8参照)、仕様と設計は図10に見られるように各開発サイクルで更新される。,,,,,
,SOTIFの作業成果物は、それが仕様と設計に影響するなら、既存の関連する内容を含んで、仕様と設計に紐付けられる、これは前のイテレーションからのすべての情報が補足され、仕様は次のイテレーションサイクルのために準備できることを確実にする。,,,,,
,注記,仕様と設計のトレーサビリティと完全性(作業成果物5.5)は、SOTIF方策(作業成果物8.5)と紐付けて、実証されえて、それらは更に以下と紐付けられる。,,,,
,,・関連する設計文書,,,,
,,・以下からの作業成果物,,,,
,,,"・Clause6　識別された有害事象の評価(例えば、S=0,C=0の達成、あるいはより制約の少ない受諾可能基準)",,,
,,,・Clause7　可能性あるトリガー条件へのシステムの応答の評価(受け入れ出来ないリスクを示すトリガー条件の分析へのリンク),,,
,,,・Clause9 & 10,既知の有害シナリオの検証報告(例えば、有害シナリオあるいは妥当性確認ターゲットに関する受け入れ不可能な性能を示す性能妥当性確認テストへのリンク),,
,,,・Clause12,SOTIF関連論証(例えば、リリース要求の却下理由を記述した報告書),,
,,,・Clause13,市場監視(例えば、新しい有害シナリオが、市場監視中に発見されたという報告書),,
,Clause6とClause7でのリスク評価に関連したSOTIFの技術的仮定は、Clause8(8.3)のSOTIF方策と関連する必要はないが、仕様と設計にトレースされうる。MBDと異なるモデル成果物(要求事項、コンポーネント、インターフェース、分析、テストおよび結果)間の自動トレーサビリティを提供する設計ツールはこのプロセスを支援できる。,,,,,
,5.4 性能不足と対策の考慮,,,,,
,設計には、車両レベルでの有害な振る舞いに繋がる可能性のあるエレメントの出力値に起因しうる可能性ある性能の制約の考慮を含む。可能性ある性能の制約の不完全なリストは以下を含む,,,,,
,,・クラス化の不足,,,,
,,・測定の不足,,,,
,,・追跡の不足,,,,
,,・ターゲット選択の不足,,,,
,,・運動学的見積もりの不足,,,,
,,"・ポジティブ検出の失敗(例えば,ゴースト・幽霊物体)",,,,
,,・ネガティブ検出の失敗,,,,
,,・閉塞域と言った、運転ポリシーレベル制約,,,,
,機能不足とそれに対応する車両レベルの有害な振る舞い識別する取り得る手法のガイダンスはB.3で見つかる可能性がある。機能不足は、システムが特定のODD(運行設計領域)で運用する時にもっとも関係する。システムがその特定のODDの離脱を検出するやり方、、遷移中にどのように運用するかは、完全な分析の支援に関係する。,,,,,
,システム開発は設計での性能不足に関係して立てられた仮説に基づく。方策はそれらの性能不足に対処してSOTIFを達成することを確実にするために実装される。設計と、仕様や設計に組み込まれた方策は、残存リスクを低減し、全体を通したロバストネスを向上させる(図5と6参照),,,,,
,,注記1,機能不足の可能性とそのトリガー条件を発見する手法と方策はClause7で詳述される,,,
,,注記2,冗長で、多様で、補完的(これらに限らないが)なエレメントと言った機能不足を取り扱う手法と方策はClause8で記述される。,,,
,,注記3,仕様と設計のSOTIFの内容はClause10で詳細に述べられる,,,
,以下は性能制約と可能性のある対策、仕様と設計文書に含まれる内容の例である,,,,,
,,例1,車線保持といった機能のための、高速道路車線境界検出アルゴリズムは、高速道路上の破片などのために正しく車線を判定しないかもしれない、しかし、衝突(訳注：誤判定のことか)による車線逸脱は、他の自動運転機能、公詳細地図と車線確認のためのローカライズ、前方車両の軌跡を用いた車両軌跡の理論付け、たとえそれによって車線を離れることを意味しても他車との距離を維持することによる衝突回避アルゴリズム、などによって緩和されうる,,,
,,例2,物体認識アルゴリズムはスケートボードに乗った人を歩行者として検出するが、その物体をスピードから(歩行者としては)もっともらしくないとして伽かする。スケートボードとの衝突はこのケースでは、物体認識アルゴリズムと処理アルゴリズムとの間の抽象化システムおよび他の異なる確からしさチェックで緩和される。,,,
,,例3,三次元的な幻影に見えるように描かれた横断歩道(図10参照)は、とあるエリアでドライバーに警告的に使われる。この画像イメージは、人の近くを騙すように路上に描かれて、存在しない物体として検知されるように視覚認知システムさえも騙すことが出来る。このケースでは、光学フローベース分析メカニズムは間違ったブレーキを予防できる。レーダーベースの環境認識と同様に、光学フロー分析はこのようなケースで、クラス化制約の代替対策である,,,
,,例4,開いたトランクから物体がはみ出た状態での自動駐車システムの利用は、有害事象に繋がり得る。システム設計での対策は、トランクが閉じた状態でのみ自動駐車システムの利用を許すことであるかもしれない。,,,
,,,,,,
,5.5,作業成果物,,,,
,作業成果物は、目標5.1a)と5.1b)を満たす仕様と設計である,,,,,
,注記1,仕様と設計は、SOTIF関連システムの要件仕様書、機能仕様書、設計仕様書と言った、複数の文書に分離されたり、リンクされたり出来る,,,,
,注記2,緩和方策のSOTIF仕様は既存の機能安全設計文書、機能安全コンセプト(FSC)及び/あるいは技術安全コンセプト(TSC)に統合できる,,,,
,,,,,,
6　ハザードの識別と評価,,,,,,
,6.1,目標,,,,
,,この章の目的は以下の目標を達成することである,,,,
,,a),車両レベルで定義された意図機能から起きるハザードは、システマティックに識別されなければならない,,,
,,b),意図機能の有害な振る舞いおよび有害な振る舞いが危害に繋がり得るシナリオから起きるリスクは、システマティックに識別され評価されなければならない。意図機能の振る舞いが有害であると考えられる環境を定義するパラメーターは仕様化されなければならない,,,
,,,例,そのようなパラメーターは、速度超過や、他の物体との最小距離でありえる,,
,,c),残存リスクの受け入れ可能基準は仕様化されなければならない,,,
,6.2,概要,,,,
,,この章の目標を達成するために、以下の情報が考慮されうる,,,,
,,,・5.5に乗っ取った、仕様と設計,,,
,,,・受け入れ可能基準を導出するための利用可能なデータ,,,
,6.3,ハザード識別,,,,
,,機能不足に起因するハザードは車両レベルでシステマティックに決定される。システマティックな識別は、最初は機能と機能不足によって起きる可能性のある逸脱の知識に基づく。これはISO26262-3で指定される手法を適用することで達成可能である。ISO26262シリーズおよびこの副章の両方で要求されるハザード分析の共通エレメントの図示は、AEBシステムを例題として図12からの用語がどのように使われるかを示す図12及び図13にある。この例は二つのハザードが同じ有害な振る舞いに起因することを示す。ハザード分析の適用はAEBを例題に使ってA.2でより詳細に述べられる。,,,,
,,例1,AEBシステムで意図機能の有害な振る舞いと誤動作の両方からに起因するハザードが起こりうる。機能制約の外部および内部での意図しないブレーキによるハザード、ハザード分析とリスクアセスメントで機能安全の側面から分析できる。機能制約内部での意図しないブレーキに関連する同じハザードがSOTIFの分析対象である。,,,
,,注記1,ISO26262-3とはことなり、SOTIF関連ハザードの分析の際には、有害事象の為のASILは決定されない。しかし、深刻度(S)、暴露性(E)および制御可能性(C)というパラメーターは検証労力の調整のために使用されうる。,,,
,,注記2,発生程度は、機能の運用フェーズ中のトリガー条件への遭遇可能性を反映する,,,
,,トリガー条件の発生と、ハザードが危害へと繋がるシナリオへの暴露には、重要な違いが存在する。一般的に、トリガー条件はシナリオから独立していない。それゆえ、リスク低減の論証の中でシナリオへの暴露を使うために、シナリオに入っている可能性とトリガー条件に遭遇する可能性の間の統計的な依存性は評価において考慮される。,,,,
,,例2,シナリオが高速道路での運転の時、高速道路パイロット(訳注：運行支援の意味か？)のトリガー条件のための統計的な独立性は仮定されない,,,
,,SOTIF関連システム関連ハザードが制御可能であるか(10.6および表10参照)を評価するためにパラメーターC(制御可能性)は使用できる。交通参加者の反応に関する研究あるいは仮定は、制御可能性の評価のために使用できる。,,,,
,,注記3,図13の例は結果として起きるリスクは二つのレベルで評価されうることを示す：最初は所定のシナリオで特定のハザードに関係するリスク、二つ目は、有害な振る舞いに関係し、いくつかのハザードと対応するシナリオの評価を含む、すべてのリスク。,,,
,,システマティックな識別に加えて、、可能性ある機能の逸脱に起因して、ドライバーあるいは使用者とシステムの間の、合理的に予見可能な誤使用を含む相互作用の考慮によって、さらなるハザードが識別されうる。合理的に予見可能な誤使用は、ハザードとの気安い(カジュアル)つながりによって区別される。意図機能の間接的な誤使用が制御可能性の減少を引き起こしたり、あるいは有害な振る舞い(例えば、不注意なドライバーあるいは機能の制約を誤解しているドライバ)の結果として起きる有害事象の深刻度を増加させたりする一方、意図機能の直接的な誤使用はトリガー条件に繋がる。,,,,
,,合理的に予見可能な間接的な誤使用の識別、およびその影響の分析は、Clause6でカバーされる,,,,
,,注記4,7.3.4とB.1は合理的に予見可能な誤使用の分析の一般的なガイダンスを提供する,,,
,6.4　リスク評価,,,,,
,,リスク評価は、あるシナリオでの有害な振る舞いによるリスクの評価を狙いとする；これはSOTIF関連リスクの受け入れ可能基準を詳しく記述することを助ける,,,,
,,注記1,車両レベルでの機能不足に起因する有害な振る舞いは、この評価の一部である,,,
,,"危害の深刻さ、および有害事象の制御可能性は、ISO26262-3:2018,Clause6で述べられる手法を使って評価可能である。分析手法が共通していても、SOTIF分析の特定のハザードについて観測される成果と見込まれるパラメーターは異なり得る。",,,,
,,注記2,ISO26262-3は制御可能性、深刻度および暴露性のクラスを紹介する。Clause6のコンテキスト内でそれは、一般的に有害事象が制御可能であるかないかのいずれか、あるいは危害に繋がるか繋がらないかのいずれかだけに関連する。暴露性はClause6のリスク評価のための決定パラメーターではない。リスクがシナリオの中で評価されるように、それら(シナリオ？)の選択は、それらへの暴露がSOTIFに関連することを、すでに暗示しているか、さもなければ分析で考慮されないだろう,,,
,,注記3,特定のシナリオへの暴露は妥当性確認ターゲットの使用として考慮されうる(Clause9参照),,,
,,例1,自動緊急ブレーキによって起きた、ホスト車両(訳注：事故相手のことか?)との後方衝突の深刻度は、ブレーキ介入程度を制限することで低減可能である。程度制限は制御可能性を増すための安全方策、あるいは意図された振る舞いへの機能修正と見なせる。ハザード分析の際、制限は意図された振る舞いの一部として考慮される；それにくらべて、制限の実装に関連した故障は、ISO26262シリーズと言った他の安全規格の対象となる。,,,
,,有害事象の深刻度と制御可能性は、引き起こされるリスクが所定のシナリオで不合理であるかを決定するために考慮される。深刻度と制御可能性の評価は機能仕様(Clause5の結果としての仕様と設計に準拠する)を考慮する。制御可能性が「一般的に制御可能」(言い換えるとC=0)と評定されるか、あるいは深刻度が「危害を引き起こさない」(言い換えるとS=0)と評定されると、不合理なリスクがないことが確立する。その他のすべての場合、有害事象はSOTIF関連と考えられる。対応する有害な振る舞いは、速度超過や他の物体との最小距離と言った測定可能なパラメーターを使って記述される。制御可能性評価は、ハザードを制御するための関与した人間による「無応答」あるいは「遅延した応答」を含む、例えば、合理的に予見可能な間接的な誤使用の結果として。この評価は外部方策と考え得る。,,,,
,,例2,ADASによって安全なやり方で取り扱われない、それゆえドライバーが制御を取り戻すことが要求されるような環境条件は、制御可能性評価に影響し得て、有害事象評定のために考慮されうる。,,,
,,ドライバーに十分な状況認知とリカバーを達成するために必要な時間を含む、ドライバーによる遅延したあるいは不適切な応答は、制御可能性評価に影響し得て、SOTIF関連システム関連分析の議題である,,,,
,,機能修正(Clause10)のあとで、有害事象がS=0あるいはC=0と判断された場合、ハザードは寿武運に対処された,,,,
,,例3,表3はAEBシステムについてのSOTIF関連有害事象の可能性のある結果の評価の例を提供する,,,